Certain services require express reservation of resources within the network.
Certain networks, including the Internet, were designed for transmitting data, but neither voice nor video. Within the Internet, transmission takes place in the form of packets, each packet being conveyed independently of the others. However, voice and video transmission need to minimize jitter, i.e. the mean difference in transit times between any two packets in a given transmission, and also overall transit time, so as to ensure that listening or viewing at the destination are sufficiently comfortable.
This minimizing of jitter and/or transit time is conventionally performed by reserving dedicated resources within the nodes of the network, commonly called “routers ”.
Nevertheless, it is clear that there is a need to control such reservation of resources. It is necessary to verify that a request for resource reservation is made by an entity having sufficient authorization to make such a request, and in particular an entity that has taken out an appropriate subscription for using the network.
When there are incompatibilities between a plurality of requests to reserve resources, for example because they require the same network element to be reserved at the same instant, this can lead to managing priorities.
To be able to do this, resource-reservation requests must be sent to an authorization manager, commonly referred to as a policy decision point (PDP) which implements this control.
FIG. 1 is a diagram of an example of a network suitable for implementing the invention and showing the context in which such a policy decision point operates.
A user A seeks to set up a voice call with a user B through a data network N. User A is connected to the network N via an access node or “edge router ” RA, and user B is connected to the same network N via an access node RB.
The resource-reservation request is conveyed to a policy decision point M. By way of example, this request might come directly from user A via an arrow referenced R1, or from access node RA via an arrow referenced R2.
If the request comes from the user, it can comply with the session initiation protocol (SIP), for example, in compliance with the Internet engineering task force request for comments (IETF RFC) No. 2543.
If the request comes from the access node RA, it can comply with the common open policy service (COPS) protocol in application of IETF RFC 2748 published in January 2000.
The function of the policy decision point M is then:                to verify that the request can indeed be authorized. This verification can be performed, for example, firstly as a function of the resources that are presently available in the network N, and secondly as a function of the subscription taken out by user A; and        where appropriate, to make the resource reservations corresponding to the request with each of the nodes concerned within the network N.        
Consequently, in that mechanism, any resource-reservation request terminates in the policy decision point M.
This gives rise to various problems:                the policy decision point needs to handle resource-reservation requests of different kinds (video, voice, . . . ) and of different characteristics (low/high data rates, . . . ). It therefore needs to contain all of the logic necessary for processing such requests, and in practice this is not possible given the rapid evolution in the types of service that are available in this kind of network; and        when there is a change in the policy decision point (delivery of a new version), any personalization or parameterization that might be requested by the operator running the policy decision point cannot be taken into account.        